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Specification and Drawings, as originally film,|witfti^ppU for Patent Serial No: 
2,293,765, on December 23, 1999, by SOLlf^NINC LTD., assignee of Tim Wilson, for 
"Internet Access Server". ' 




RELEVANT AREAS OF TECHNOLOGY 



The invention pertains to: Internet access for mobile customers, access to World Wide Web from 
a Multi-trade of locations with zero configuration changes to the Customer/Client's Personal 
Computer and access as if they were at their home/office locations. 

EXISTING PROBLEMS IN THE ART 

Access to the World Wide Web has been via telephone access modem, which has also tied up the 
Hotel's telephone lines and PBX resources. 

SUMMARY OF INVENTION 

According to a embodiment of the invention, a server provides plug in and Go access to the 
World Wide Web with zero change to the Clients Computer. Nor additional software/hardware 
is added and no configuration or hardware changes are required to the computer. 

Among the advantages of the present invention are ; it is easy of use, no changes are required to 
the fundamental resource the Clients personal compute, the Hotel gains revenue or a selling 
resource to offer Client's and reduces demand upon the PBX. 

The Solution IP Product is an Internet Server buih on a Linux based software platform (Red 
Hat). This server resides in a Data Network between a Hub that faces an Internet Providers point 
of presences on the WWW and an Internal Data Networking of Switches providing Data 
communications to Clients in rooms and conference centres. 

An embodiment of the invention uses Static IP routing. The server is provided with a number of 
Static IP's. When a Client connects to the server via the Internal Hotel Networks; the IP on the 
Clients PC is removed fi-om an all external Internet traffic and replaced by the static assigned by 
the server. 
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S lutionIP™ Patent Application 

Technical Description 

SdutlonlP^is a VBN (Visitor Based Network) communicefion feehnctogy that enables devices 
communicating with the TCP-IP protocol (the communications protocol of the Internet) to 
seamlessly gain access to a any foreign TCP/IP netwohc thai has been connected to a 
SoiuiionlP'^senrer, without requiring those same end users to make any TCP-IP configuration 
changes to their existing computer systems. In a traditional TCP/IP environment a user would 
have to manually re<onf!gurB a device such as notebook computer to gain access to a foreign 
(non-company controlledjTCP^IP network. 

It can also be assumed that many different current TCP-IP and operating system solutions could 
be used to establish a connection to a TCP-IP network such as the Internet le one user might be 
running TCP-IP on a windows NT platform with DHCP enabled, while another user might be 
running a Unix machine with static IP, DNS and gateway addresses installed. Both wiJI allow 
access to the Internet if properly installed and connected to a network that has been setup to 
grant them access to TCP-IP services such as the Internet. 

The problem is that these same users would not cun^ntly be able to take their notebooks that 
have been configured to work on their employers office LAN/WAN and plug it Into another 
"foreign" network and expect It to work. They would have to first manually configure their 
computer to work on the foreign network - a task most users would not be able to accomplish on 
their own without the support of a network expert. This Is obviously not a practical, cost/time 
effective and realistic task to expect people to use. 

The reason fw this traditional method of obtaining TCP-IP services such as internet access is 
twofold. 1 ) A general belief by end users that this is their only option and 2) Current TCP-IP 
communications protocols in all operating systems I.e. unix, linux, windows. MAC. etc have been 
designed to operate in a preset environment and not to be mobile - that's what modems and dial- 
up networking is for. Modenr^. even the fastest 56Kb/s ones, however, are frustratlngly slow 
compared to the speeds that can be obtained on a Ethernet network connected to the Internet at 
T1 or faster speeds. They also depend on the user having a valid account with an ISP to gain 
dial-up access to the net. This is fine if you use the net sporadically and can obtain local (i.e. no 
long distance connection needed to reach your ISP) service. This however, is not the typical case 
- business people are continually using the net n>ore and more via email. Intranets and Extranets 
and more often than not have an Internet sen/ice that does not provide for local connections 
wherever they go. For example a user from Halr^ that has a ISP account with iSTAR Internet 
and who was travelling to Nfld. to do business would have to dial long distance back to Halifax to 
make a connection because ISTAR does not have a local Presence In Nfid. 

What problems does SolutionIP sohre? 

SolutionIP technology overcomes all the above issues and truly gives mobile users the ability to 
access TCP-IP sen/ices, regardless of their systems cun-ent TCP-IP configuration by simply 
plugging in their NIC (and not a modem) into a data Jack In the wall and instantly gain access to 
high-speed TCP-IP based services without any requirement to have an account with any ISP 
whatsoever. 

It also allows fbr various authentication methods depending on the environment it is Insbtled in 
For example: In a hotel you might only want to authenticate based on a user accepting the terms 
and conditions and posted daily usage charge for the accessing the system. 

In a corporate boardroom the system might require the user to supply an access oode and ID 
before gaining access to the system. 
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The SolutlonIP server accomplishes Ihis task by forcing the user to launch their favorite web 
browser which then provides the user with a web page that prompts the user to enter more 
information or to dick on an accept usage conditions/charges before the user Is allowed further 
access to the TCP-IP network that they are attempting to access. The information that the user 
provides is then associated in an SQL database hosted on the SoluticnlP Server with the users 
unique MAC address and/or combinatton of other unique Identifiers such as an account/ID 
number, credit card number, firequent filer number etc. to determine if the user is allowed to 
access the system. If the user provides the correct and required information to access the system 
Ihey will be allowed access for the time period (In minutes, hours, days etc.) that the log on 
screen has informed them of. Once that time period has expired, they will need to re- 
register/authenticate again. 

SolutlonIP also has the ability to accurately account for and when necessary bill for usage of the 
TCP/IP nehwork the user is connecting to. In many public areas such as a hotel room there Is a 
requirement for the SolutlonIP server to "know" which room a user is connecting from in order to 
accurately bill that particular room for usage of the system. This is important because you do 
want to present the customer with the option of entering their room number manually. If this were 
the case the customer might enter a felse number which would cause the system lo bill another 
guests room which would create havoc from a billing/customer service basis. 

To overcome this obstacle SolutlonIP is able to intelligently detect which *porf on a data networi< 
user is connecting from by associating the MAC address of the user with a port on a networi< 
device such a switch port on an Ethernet switch, cable/xDSL modem or other network 
connectivity device. The port number will be associated with a room or other unique billing 
number In the SoluticnlP database which will ensure the that if a user connects through that port 
the proper room/account number is billed. The SoluticnlP sen/er accomplishes this task by 
examining and reading the SNMP (Simple Network Management Protocol) MIB In the network 
device's registry table and sends this information to the SolutlonIP sen/er database which in turns 
sends this Information to the billing device, such as the PMS (property Management System) in 
the hotel. We refer to this application as "Port based billing and authentication" 

Technology Involved. 

Specifically SolutlonIP^ is a highly modified version of the Linux OS operating system and 
custom built drivers on a PC based computer platform with two network cards, a hard drive, a fast 
CPU and adequate RAM. The server is presently configure lo operate In an Ethernet/Fast 
Ethernet environment, however, the server technology itself is network transport layer 
independent (it could operate just as easily In an ATM. Token Ring. Dial-Up or other). The 
currently deployed SolutlonlPTM servers need to be located at each physical location where the 
service is to be deployed. Solutionlnc is currently developing a "Carrier Class" SolutlonIP sen/er 
that will sit in a large service provider, such an ISP or Cable Operator's Head End NOC (Network 
Operations Center) and be able to sen/ice many different properties from a central point. A clear 
example of this solution In practice would be a cable provider that offers high-speed Internet 
using DOCSIS compliant cable modems could simply install a cable modem in each hotel room of 
a building and mn them back to their cable headend equipment If our SoluHonIP sen/ers were 
installed at the cable headend, any user attempting to connect to the system would be given the 
same translation, registration and billing options as our on-site SolutlonIP server option. This is an 
Important feaure as it will allow large service providers to roll this service out to many buildings 
without having to Install expensive on-site networidng equipment and data wiring at each site. 



CA 02293765 1999-12-23 



03/03/1999 MON 13:45 FAX 9024634823 PHASE REMEDIATION ISC 



Supp rting Information 

SolutionIP end-user cli nt required minimal configuration 

SoiutiOiffF^hzs been designed to provide "Plug N* Go" Internet access, whereby users wiil rH 
not have to reconfigure network settings to connect. However, certain system configurations wil Cr> 
require users to make minor changes lo their network settings. Specific configurations thai will ^ 
require changes include the following: 

1 . Applications which are proxled will not work until the proxies are disabled. (See HOW TO 
section for disabling Netscape and Internet Explorer proxies.) 

2 Browsers and emaO applications which automatically initiate a modem dialup connection on 
startup must disable this feature. (See the HOW TO section to disable this feature in Internet 
Explorer or Netscape and Outlook). ^TTi 

• Systems configured with a static IP are supported, however gateway and DNS addresses 

must be specified. Active mode FTP will not be available to these users. QJl 

Frequently Asked Questions 



1 . What doM SohiHcatf^" do? 

. eolutiMlP™ prwHS9a Plug N* Go Internet access for both sts^ IP and DHCP IP enabled dovtces. Most clients wiii 
beabfeto eeamlessfy oon/ied to a SolutionIP^ enabfed network without neonfigunn^ IP ^etffngs, AU charges wHi 
be billod dkoedy to your room's foGo. 

2. What operating systems doss SofuUonlP^exipponn 

• ScSutlen/P^ is able to support any operallng system with a TCP/1 P communicalions protocol stack which 
Indudss: 

^ Windows 3,1 , 95» 98 and rrr 

A |y4acOS7.5.1and8 

=D Unix, Solaris. LiNUX 

» Other OS systems being tested 

• The services provided by the SoiuUontP^r\a^otk are compaitole with and transparent lo most TCP/IP 
networking systams. (Sae Umitattons section). 



X What is required to uss SoM^tUP^ 

• An Ethernet Network Interface Card and connector. 

• A web browser. 

• ATCP/IP Stack. . A u , . 

• In adcfilion. the TCP/IP stack should be configured either for a dynamic network conflguraHon or for a staKc 
network conflguraBon. If a sUtic network oonflguradon is being used, an IP address end subnet masic must be 
specified, as welt as at least one DNS server and a gateway. The gateway must be on the same subnet as your 
computer's IP address. 

4, What are the benefits of using S^utfonlP^ 

• Higivspeed access to the Internet without having to change your netwoik settings. 

• Does not lio up your room's phone Una. 

. Aooess to hotel services arnJ local Infemnatten via VlrtualCONCIgROEw^ ^. . ^ ^ni«-rf 
. Increased productivity due lo tast connection - no long delays waiting tor large emaU attachmenb to downlosd 
via modem. 

• Reduced costs - no long distance charges necessary to connect to modem sender. 
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3, Do I nflftd to Mall any ipecial »oft»«r« on my compiaar to u«« SctoHotU^ 

. A8 long as you have me minimum requirem«nb spedflad, you do nol need lo inatan any additional software to 
use SoiufionlF^ 

6. Is Maki*iani0^ a MCUT* Inttmat and notworic aecM product? 

• fc*rtAmi^«rehiteclure udlizea switched Ethemal nohwjrics to prolad guestTs network traffic from oth«r 
guasts. In addition, guaata af« firaa to uao any of a variety of secure IP-*ased communication protocola and 
products to protect their data on the Internet 

7. Why doean't my FTP diant work? 

• Ensure that you are reglslered. (See HOW TO fiecBon.) 

. If you are using a static IP conflguralicn. you must use paaatva mode FTP. Consult your appUcatlcna help 
section to determine If passive moda FTP ta supported. If your FTP diant doas not support passive mode, you 
can try using your web browser to access the FTP site (most web browsers use passive mode FTP) or change 
your neMi/ork settings to use a dynamic net«vorfc configuration. (See HOW TO section.) 

a. Whan I try to accoaa my amati / web bf owsar. II always Wea to use a modem connection. How can ! gat rtd of 

R7 

. The tnatAiCtlona for diaabBng Internet Exptorer automatic modem connections are descrtbed In the HOW TO 
section. 

9. When I tiy to acceaa a aita with my wab browser, nothing aeema to happen. 

• Your web browser may be configured to use prosdos. To (fisabia proxies, fbaow the steps in the HOW TO 
section. 

10. Why can't I acceaa my company's Internal email server / web aerver/ ... ? 

• Since Bokitfanff^ Simply provides guests with access to the lntemel» any attempts to access your company's 
computing resources would be routed through the Internet Your company may have placed security barriers in 
place to prevent unaulhorlzad access from the Internet. If this is the case, your attempts lo access the company 
systems may bo Wodted by such security measures. T7 accessing a public wab site, such as 
htl^://www.yahooxom* If you are able lo access the public site, your Internet oonneclion from the hotel is 
working property, and the connection difficulties must be related to your company's aecuilty measures or 
Internet connection. Consult your company's Infofmelion Services department for assblance, 

11. When I try to access my email using Netscape maH nothing seema to happen. 

. Nalscape may be condgurcd to use proxies. Follow the steps described in the HOW TO section to disable the 
proxy. 

12. Why ean'l I access my NoveR server / IPX nehvork / AppleTalk network / etc? 

• jffoM/orti^onty deals with network traffic based on the Intamet Protocol (IP). Other types of natwo/k 
protocols are not cuaentty si^ported. 

13. I have an application which uses MicroaofTs DOOM, but it doesn't seem to work in the hotel. What Is wrong? 

• DOOM, as wen a« some other types of protocols, embed Infornialton about your netwoik addrwa in ihe date 
they aand. M your computer is using a static nrtwork configuration. SolulksnIP'** wBI translate the network 
headera of the data you send out over the Intemel so that It appears to be coming from a ncNwrk address 
associated wtih the hotel. When the DCOI^ appUcadon at the other end receives y«J'^<iato. jho return 
addresses in the OCOf^ data and network header wlU not match. The DOOM application wifl than be unaWa to 
property process the request In order to use your DCOW spplfcatton. you must change your network settfngs to 
use a dynamic network conRgunitian (eee HOW TO sectton). 



CA 02293765 199912-23 



35/03/1999 MON 13:46 FAX 9024684823 PHASE REMEDIATION iNC 



14. My Virtual Prtvato Nttowortt / Korbtret / IPSec / Mobile IP / softwire won't work. 

. Similar to DCOM (see above), many of theso appUeatfons emb«J Infbnnatlon about youf computer's network 
addresawtthinth data they sendJf you are using a static network conflgufaton, «ofti«to*Trf^ will translate 
tne return address that appears tn the networfc headei^ of your data ao thai it appears as if your data is 
ortalnaUng from an addr«« assocrateo wfth the hotel. This allows responses to be relumed to you prope/ly 
under normal drcumslanccs. These protocola. howevar, are sensWvo lo this type of trwslalion, and will not 
allow It You must change your computer's nelwcrK settings to use a dynamic network configuration in order to 
use these protocols (see HOW TO section). 

15. How do I know tf 1 am using a static or dynamic IP configuration? 

vyin49ws??orMr 

a) Select the Start menu 

b) Select Settings 

c) Select Control Panel 

d) Double aick on -NeNvorfc' 

e) Under the Configuralion tab (95) or the Protocol tab (NT), you should see a lUt Hot enbtted TCP/IP 
ProtocoT or TCP/IP binding for [product name] Ethernet Adapter. 

f) HighKght tWs list item and cfick on the PToperHas buaon. 

g) Under the IP Address' tab, the opdon entfUed "Obtain an IP address automaticafly" (95) or ^Obtain an IP 
from a DHCP sarvai' (NT) wiB be seJecteO if you are using a dynamic network oonffgurailon. If you are 
using a static network configuration, the apdon enUited 'Sped^ and IP address:' will be selected and the 
cwo text boxes In that section should be fflieo in. 

16. How do I know If I have a TCP/IP stack Installed? 

yyflndowsflSorNT 

a) Select the Start menu 

b) Select Settings 

o) Select Control Panel 

d) Double Click on •Network" 

e) Under the Configuration tab (95) or the Probcol tab (NT), you should sea a list Item entitled TCP/IP 
Protocor or TCP/IP binding for [product name] Elhemet Adapter* , 

f) if you see an opUon of this type, you have a TCP/IP stack installed. 

17. How do I change my cemputer to use a dynamic network configuration? 
• Complete Instrudions are given in the HOW TO section of this manual, 

1 a. What type of technology is BofutiantP'^ huWi on? 

. Tlie SoluttenlP« Is built on a customized Red Hat Linux kernel and unlqus drivara. 

19. What eaeurtty faaturai does mo/urtcmft''' support? 

• ma0uvionS^Qf(cn a flexible authentication scheme that can be customzed for different instailations. It is capable 
of logging traffic to detect incoming or outgoing attacks. 

20. How does A^et^hyetan/P' compare to DHCP? 

• aoA/eteni^ supports DHCP aa a subset of me complete sendee offering. UnOke DHCP, fria «i 
can provide network access whether or not the dient ocmputer has been OHCP enabled. 



SalutionlP^ Illustrated 

Joe Salesman is an accounl executive with a major publbhing company. Joe's company has been very proactive in 
keeping up with technology, ensurtag employees have access to up-to^iate computers and network resources 
Including a company-wfde Intranet Joe knows thai when visiting customers, both locally and when he's on the road, 
remote access to Email, documents on his corporate intranet and prospective dlent Web sites is a professlorwl 
necessity. 

Joe has been asked to dose a deal with a prospective dient who is njmored to be displeased with their current 
pubflsher, Joe's main compedlor. With Ottle time to prepare, Joe books a (Bght tor the feltewing morning as wefl as a 
room at a hotel h the dfenf s dty that offers high-spaed Internet access. Joe catches the light but realizes he Is 
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This scenario demonstrates just a few of the capabilifles and applicafions of SduttonlP™. The intemebworking 
professionals at SohJllonlnc UmHed would (he lo discuss how they can make this technology worK for you! 



CO 



missing a key piece of infbmiation which he will need to retrieve from his corporate Inlranel as soon as he can get an 
Internet connection. 

Upon arrival al the airport Joe heads to the frequent flier lounge and asks the host if there Is an area where he can get 
an inlemel connection. The host Intorms Joe that Iheir airline has recently Installed a system called SoiutonPORT^ 
from Solutioninc Limited thai uses Solutior IP™ technology to provide members with immedate high-speed access to 
the Iniemet. After plugging his notebook's NIC into one of the data jacks in Ihe lounge and launching his Web brovraer, 
Joe is pleased to discover he Is connected! No need for a local Internet account No need lo incur long distance 
charges. No need to suffer the sluggish speed of a diaJ-up connecdon. No Imstrations with network settings. In 
seconds, Joe Is colecting his Email and downtoading the required ftte from his corporate Intranet! ^> 



Joe then proceeds to his hotel. Checking in. Joe b kifbrmed of Ihe high-speed Internet access avaHable from each 

guesrs room. Throu^ Ihe hotefs SoMdonGUEST^ system, which incorporates SdutionlP™ technology. Joe simply m 
plugs his notebook Into the data jack h his room, launches a Web browser, dicks to accept the $15 per dem charge 
and he's off to the internet to prepare for his big meeting In the mcming! 
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Here are some more vertical markets where SolutlonIP as a standalone product 
will be deployed In to provide VBN applications t mobile professionals. 

Training Centers - This would malce it much easier for people to use their own 
notebooks. 

Large Libraries - again many libraries are already gearing up to allow people to 
use the WWW and find information digitally. This would make it much more cost 
affective by not having to supply and maintain as many library owned PCs. 

Kinko's type places. Instead of having to use the PC's it would be east to put a 
e-commerce finont on SolutloniP so clients can use the Kinko's connection and 
Printers on their own machines. 

Shared offlce/Hoteling facilities such as IB Your Office - 

www.lbvourofflce.com This would give them a real edge and reduce their admin 
MIS costs plus add more billable services to their offerings. 

Educational dorms and campus's - this would ease the demands of IVIIS staff 
to manually configure 100 or thousands of students as they register for school 
each year. It wouW also students to moves back and fourth from off-school 
networks such a scalable modem service at their apartment or home and unto 
the school network. 

IManufacturing facilities and production lines - their is huge opportunity In this 
field to use the Inherent "follow me" and dynamic registration ability of SolutlonIP 
to in effect "push" software an applications at a users specific to the area/ "IP 
zone" of the productton floor they are say with a wireless connection 
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Financial Trading hous s - much the same as above -their Is a tremendous 
K of moJls add changes regularly taking place here. A person mlgh move to 
another area of a floor and automatically have that areas applications pushed at 
him, 

Portal/Advertising revenues/license fees from companies that wish to ensure 
their message Is seen at least once. 

Branch/Remote Office - where people are regularly coming to and from foreign 

Svemment, All levels - self sen/ice Kiosks or areas such a business 
development centers v«^ere they provide help and Infomatlon to people wanting 
to start their own businesses. 

Airport fraquent flier lounges and general waiting gate areas you coukJ 
quickly add data ports near many phones you see In airports with e-commerce 
interfaces. 

Ucensing arrangements with ISP's and other Wired and Wireless network 
providers. 
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A) Technical Description 

notebook computerto gain access to b foreign (no.i-companyconrmnL%TCP% ^^^^ 
It can also be assumed that many different current TCP-IP and ooeratina svstam soii.H«nc «. 

grant mem access to TCP-IP services such as the Internet. 

SvVtoen TnSfi'rnllJf '^""''""y aWe to take their notebooks that 

?o^Son- «'"P'°y*'* LAN/WAN and plug it Into anoSfw 

ToiSl^r^^ and expect It to woric. They would have to first rronualfy wnfiflurJ thJr 

Jrsr/:7o^. '5oXrer.rertLT5^^^^^^^^^ - ^^'^ t ^s-Ta^d's. 

compared to the aoeedsn^ti^n^H!^^^ tit °"*f ' frustratingly slow 

any ISP whSWv^f "''^^ requirement to have an account with 



B) Technology Involved, 



CPUamjadeauMiBiiu '^J^ ""PWerKalformwilhtwii nxwork ear*.ihart(lrive.arasl 
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fellowing pages and slides give a more detailed and graphical depiction of SolutionSERVERn. in 
action. 

C) Supporting Information 
Some FAQ's 



ULJ Q. What does SohitionSERVER do? 

—J A^SolutionSERVER is able to provide translation services for computers that suoport Ethernfl^ 
"J This allows the computer to operate in a "fcrelgn" LAN. regardless of the original lP address or 
^ configuration of the computer. SolutlonSERVER does not require any special software or end- 
user configuration. 

^ Q. WItet client operating systems dees SolutlonSERVER support? 

^ i"J]!llf2--!l?"lw^''^^'? '* '"PP*^ operating system with a TCP/IP communicaUons 
< Kf^f JJ».f?""?* i'"""*^^** SolutlonSERVER are fully compatible with and 
jransparent to TCP/IP networtiing systems. 

°' technology is SolutlenSERVER built upon? 

LJJ Q Itelf£llSS'l5Sy!«'l''l'''i.°" '■inux kernel and unique drivers. 

Ur' a. MOW many ueers can SolutlonSERVER support? 

>V A base SolutionSERVER is capable of supporting between 100 and 400 simultaneous users 
depending on traffic flow and conflguraUon. Higher numbers are easily achievable with more 
server horsepower, 

Q. What security features does SolutlenSERVER support? 

A SolutioriSERyER Is capable of authenUcating based on usemame and password. IP address 
or Ethernet MAC address or any other high level of authentication such as a secure ID card It is 
capaoie or logging all traffic to detect Incoming or outgoing attacks, and provides remote 

O S d«f '^.1?i*"5lS'!,2^f''*y' '^""9*^ « section, 
a. How does SolutlonSERVER compare to DHCP? 

'iS^T^^'ii''^^^ P."^^ ' °' "'"P'^'s offenifl- Unlike DHCP, 
me SolutlonSERVER can provide network access whether or not the client computer has DHCP 
enabled. SolutionSERVER is also capable of supporting clients whose existing DHCP lease has 
noi yet oxptpBO. 

Mar Platrorm Compatibility ' ' " 

« Wlndovvs 3. 1 . 95, 98 and NT 

• Mac OS 7.5.1 and 8 

• Unix, Solaris. IRIX, LINUX 

• Other platforms in testing 

Cllant Raquirements 

• t^ntT-^^^ (SolutionSERVER can ba easily configured to run on any networking 
transport layer including dial-up) ^ 

• TCP/IP protocol stack 

SolutlonSERVER Ineludea: 

• On-lfne help Web based help 

• ConHguratlon and user manuals 

• Remote management via Telnet 

Sacurity 

' SS.IS"!^^^^'^ supports password and Mac address based security as a standard 
laaiure. however many other layers of security can be added to it's functionality. 

Data Tranamlselon Protocols 
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1 INTRODUCTION 



Solutioninc Limited defined a suite of products based on an intelligent building Internet 
conununications infrastructure, SoIutionlBS. Based on the SolutionlBS model, a number ofbuilding 
specific implementations (products) were defined. All implementations share a set of features and 
functions aimed at simplifying Internet connectivity for people living or working within a 
SolutionlBS building. Solutioninc asked Software Kinetics to develop the "Plug-and-Go" 
connectivity component essential to SolutionlBS. The "Plug-and-Go" connectivity, known as 
SolutionIP, allows tenants (or guests) in a building to re-locate and re-connect to the Internet from 
any location within the building in such a way that the Internet access appears transparent and 
seamless. 

The initial implementation of SolutionIP is for the hotel industry. The primary objective is to 
proAade guests with the ability to log into the Internet from their hotel rooms without having to 
modify their personal computer network settings. The guests will be able to transparently and 
seamlessly get their email, surf the web, etc. as if they were in their offices. 

This document details the functional specifications of SolutionIP as developed by Software Kinetics. 
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2 USAGE SCENARIO 

A typical usage scenario for the SolutionIP product consists of a business traveler requiring access 
to the company email server from their hotel room. After connecting their laptop to the hotel room's 
network jack and registering for the SolutionIP service, the hotel guest can access the Internet, as 
well as online hotel services (Virtual Concierge) using the hotel's high-speed Internet connection. 
They can then connect to the company email server via the Intemet as if they were on the company 
Local Area Network fl-AN), and at speeds much higher than possible using a dial-up network 
connection (See Figure 2-1). 



Figure 2- Usage Scenario 
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3 REQUIREMENTS SPECIFICATION 

SolutionIP is a server-based solution designed to allow users to connect a computer with a working 
Ethernet network interface card (NIC) and an IP-based network configuration to the Internet. The 
guest would physically connect to the SolutionIP system via a network interface connection. Most 
users will have seamless connectivity, however there are limitations, which are described in detail 
in Section 3.4 Client Requirements. 

Users are required to register with the system using a browser application before Intemet 
connectivity is established. The server will detect all attempts at gaining access to the Intemet and 
continue to redirect users to an SolutionIP web site until registration is completed. Once registered, 
they will be able to use the high-speed Intemet connection of the hotel to access corporate computing 
resources and email via the Intemet, browse the World Wide Web (WWW), etc. 

Guests attempting to pop their email prior to registration will be issued an email message. The 
message simply asks them to register using their browser before email can be downloaded. 

3.1 Functional Decomposition 

SolutionIP translates network traffic from client (hotel guest) computers in such a way that it can be 
properly routed to and from the client via the hotel Intemet connection. This is possible regardless 
of the current network settings (IP address, DNS servers, gateway, etc.) on the client machine, 
provided that the existing configuration is functional, (i.e. The client machine must have a working 
network configuration, although the actual addresses used are not expected to be configured for the 
hotel's network). SolutionIP will transparently translate the settings of the client machine into 
addresses appropriate to the hotel's network environment while routing data to the Intemet. In 
addition, the server will then "reverse translate" return network traffic to use addresses compatible 
with the client computer's configuration. 

More specifically, only IP-based protocols are currently supported. Other types of network traffic 
are ignored and not forwarded by SolutionIP. SolutionIP will provide DHCP (Dynamic Host 
Configuration Protocol) server functionality, which will be used to supply configuration data to those 
clients configured to dynamically obtain their network settings. DNS (Domain Name Service) 
requests are to be intercepted by SolutionIP (based on destination port number) and serviced locally 
by a DNS server running in the hotel. Outbound network traffic is intercepted by the SolutionIP 
server, which acts as a gateway to the Intemet and forwards the data as appropriate. SolutionIP will 
pretend it is the client's gateway, even if the client has specified a different gateway, such as the one 
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normally xised by the client in the office. 
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Unauthorized use of the network (i.e. network traffic fi-om clients who have not registered for the 
network service) will be blocked by Solution!? until the client registers, SolutionIP will maintain 
a list of those client computers which have been registered and are authorized to use the network. 
Traffic &om authorized clients is routed, while other traffic is discarded or redirected. Please refer 
to Section 3.3 Registration and Usage Component for further details. 

SolutionIP will not prevent facilities such as VPN (Virtual Private Network) connections and VL AN 
(Virtual Local Area Network) capabilities, however they are not currently directly supported. 

Figure 3-1 provides a functional decomposition showing the major system components and their 
interactions: 



Ouest 




Figure 3-1 Functional Decomposition 
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A guest can communicate with the SolutionIP server via Hypertext Transfer Protocol (HTTP) 
requests (the protocol used to access the WWW), or email requests (P0P3 protocol only). Once 
registered, IP-based trafSc originating firom the guest's computer passes through the SolutionIP 
server to the Hotel Services Intranet or to the Public Internet 

3.2 Security Considerations 

In general, the SolutionIP solution is not directly involved with attempts to secure the hotel network 
from external threats. Creating and enforcing a security policy for the Internet connection of the hotel 
is to be dealt with by other components of the overall solution. SolutionIP does not perform filtering 
of in-bound network traffic destined for registered clients. 

The SolutionIP server has all unnecessary services disabled and file permissions checked to try to 
prevent malicious modifications. The only login access to an SolutionIP server is by secure shell 
(SSH) or from the console, 

3.3 Registration and Usage Component 

The registration component is a web-based appUcation, which allows hotel guests to register for the 
network service, as well as log off from it. It is accessible to all guests who are connected to the 
network (i.e. access to the registration site is not blocked by SolutionIP). The web server for the 
registration component runs on a separate machine from SolutionIP minimizing the load on 
SolutionIP. 

Prior to registration for the network service, any attempts to access WWW and POPS (a type of 
email) servers are detected by SolutionIP and intercepted. This is based on the TCP port number. 
These requests are answered by SolutionIP or forwarded to the web server where information is 
provided on how to register for the hotel network service. Future expansion of the product could 
include interception of other types of appUcation protocols (other email protocols, for example). 

SolutionIP also has the ability to track registration information, vMch can be used for billing 
purposes. Currently this information is available through an administration web site that displays 
who is cormected to tiie network, who is registered, time and date of registration, etc. The server does 
not currently track data volumes, but such a feature can be implemented in the fiiture. 

3.4 Client Requirements 
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Although the system is a server-only solution and transparent to registered clients, there are certain 
minimum requirements for client computers, SolutionIP is designed to operate without modifications 
to the client's computer configuration in the majority of cases, but certain components must be 
present and working. There are some situations m which manual configuration changes (e.g. 
disabling proxies) will be necessary. A possible future client-side utility might be required to enable 
certain systems to access the network. 

Minimum client reqxiirements: 

•Ethernet Network Interface Card installed and configured, with compatible interface to hotel 
network jacks; 

•Installed TCP/IP stack, configured for DHCP or for static IP address, gateway, and DNS 
server(s); and 

•Web browser configured for direct network access (i.e. not a dialup-only browser configuration 
and without proxies enabled). (Only required for registration/log-off process and possible client 
usage). 

It must be noted that there are limitations inherent in any non-client solution. Many of these can be 
overcome by manual reconfiguration. It is important to specify that diis solution will be subject to 
the limitations described in the "IPORT^" - Version 2,0 Technical White Paper" (Pages 7 and 8 of 
11) for server only solutions. The limitations described in this white paper are discussed in the 
remainder of this section. 

Below are the areas of capability where a client component is advantageous to a server only solution. 

•"Connects users who have configuration settings that prevent connection to server-only systems 
(about 30% to 40% of users)." If the user has satisfied the minimum requirements described 
above, then they likely already have a way of connecting directly. In the rare instance that they 
are configured to access the Internet through dial-up only then manual reconfiguration would be 
required. 

•"Diagnoses configuration problems that prevent connection (about 10% of users)." A configured 
Ethernet card is a client requirement. In cases where the traveler does not normally have a 
Ethernet card installed (such as where they use a docking station with a built in card), the user 
woxild have to install and configure an Ethernet card before using the SolutionIP system. 
•"Performs quickly over high-speed connections, including fiber and DSL." Although this may 
become a problem, there are options for dealing with this when it does become an issue, such as 
using multiple servers and load balancing. This is an area that would require work beyond the 
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scope of this project. 

•"Supports DCOM standard for distributed Internet computing." If the client is using DHCP then 
this standard would be supported. If they are not, some re-configuration would be required. 
•"Supports dial-up configurations." Not supported by SolutionlP. 

•"Supports IPSec, L2TP and other Internet security protocols." If the client is using DHCP then 
SolutionlP would support this. Otherwise, manual re-configuration would be required, 
•"Supports Mobile IP standard for automatic, secure routing of information firom mobile 
computer users* home offices to their laptops." If the client is using DHCP then SolutionlP 
would support this. Otherwise, manual re-configuration would be required. 
•"Supports VPN standard for encrypted communication to corporate computers over the 
Internet." If the client is using DHCP then SolutionlP would support this. Otherwise, manual 
re-configuration would be required. 
3.5 Future Additional Functionality 

The requirements described in this document are sufficient to allow the majority of clients to connect 
easily to the Internet via hotel networking facilities. However, some clients will have system 
configurations that vnll not allow connectivity through the SolutionlP server. There are a number 
of possible additions to the basic system described in this document which could be considered for 
future releases. These additions are described below: 

•Support for additional application protocols, including other email protocols such as IMAP4 to 
provide notice to guests that they must register for the network service, (e.g. provide information 
to users of protocols other than P0P3 and the WWW, explaining that they must register before 
being able to use the network and how to do so). 

•A client-side utility to assist with configuring those systems which cannot be acconraiodated 
using a server-only solution. Such a utility could take the form of a simple diagnostic tool which 
would provide information as to why the client is xmable to connect properly, providing 
information for manual reconfiguration, or a fiilly featured application. The fully featured 
application would actually reconfigure the system for the user and then imdo the modifications 
following log-off. 

•The specifications call for only IP-based protocols to be supported by the SolutionlP server. 
Depending on demand and technical feasibility, it may be desirable to add support for other 
network protocols as well. 

•Increased support for Virtual Private Networks (VPNs) and Virtual Local Area Networks 
(VLANs). 
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•Support for SOCKS clients by intercepting SOCKS traffic based on TCP port number and 
redirecting such traffic to a local SOCKS proxy server. This sort of approach would be similar to 
that used for servicing DNS requests, and may allow clients whose systems are configured to use 
proxies to successfully connect to the network without requiring manual reconfiguration or a 
client-side utility. 

•The impact of emerging standards for enhanced security in IP networking and for mobile 
computmg such as IPSec, L2TP, and Mobile IP should be examined. Modifications or additions 
to the initial solution may be required, as these protocols become more popular. 
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4 HIGH LEVEL DESIGN 

SolutionIP can provide transparent network access via two mechanisms: 

•Network Address Translation (NAT): Each internal system is given a unique IP address to 
communicate with the Internet. This allows external connections to clients and facilitates UDP 
based protocols as well, but will require that a sufficient set of routable IP numbers be available 
for assignment at each installation. 

•Masquerading: Each internal system appears to the outside world with the IP address of the 
server. This would require the development of special protocol-aware handlers (proxies) for 
protocols like active-mode FTP which try to create independent return connections back to the 
client, and modifications would be necessary to support UDP "connections" (statefull packet 
inspection). 

SolutionIP will utilize NAT as the primary mechanism for providing transparent network access. 
Despite the problems associated with IP number allocation this choice offers the best available 
mechanism to effectively deal with various unsupported network protocols. SolutionIP will be based 
on a customized version of the Linux operating system. 

There are two main scenarios: 

•The client is configured to use a particular, fixed IP configuration: the server captures Address 
Resolution Protocol (ARP) requests fi:om the client and the server responds with its own MAC 
address. The client is assigned an IP address, which is mapped to the client's configured IP 
address and its MAC address. If the client has not "registered" for the service, then the first 
attempt to communicate with a web server or a pop server will result in a redirection to the 
registration screen (web) or a mail message with directions to the registration screen. From this 
point until the client logs off the system, their traffic is allowed to proceed unimpeded. As the 
traffic passes through the server, the IP address of the client is translated back and forth between 
the configured (fixed) IP address and the server-assigned IP address. 

•The client uses DHCP. In this case SolutionIP' s DHCP server component assigns an IP 
address and then SolutionIP acts simply as a router, except that normal IP traffic is blocked 
or redirected until the client goes through the registration process. 
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4.1 Core SolutionIP Components and Interactions 

Figure 4-1 shows the breakdown of the core components of the SolutionIP product and their 
interactions. These components are further described on page 4-3. 
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Figure 4-1 Core SolutionIP Components and Interactions 
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Components: The following are the major system components which have been identified: 

ARP - The Linux ARP service will be modified. Nonnally, a system only responds to an ARP 
request if the ARP request contains the system's IP address. Instead of only responding to ARP 
requests for its own IP address, the modified ARP service will respond to any ARP request with its 
MAC address, regardless of the IP address specified. This will allow SolutionIP to pretend to be the 
gateway, DNS server, etc. for clients using fixed IP configurations. The changes must be made in 
such a way that the modified ARP service can be enabled or disabled on a per-network-interface 
basis. 

Registration Device Driver (Soln Device) - A pseudo device driver needs to be written to manage 
the registration data. It will keep track of client IP/MAC to assigned IP mappings, registration status, 
and various time-related parameters (how long the registration is valid for, for example). The 
information will be stored in kernel memory for read-only access by other portions of the kernel such 
as ARP and the Ethernet Packet Drivers, This driver will also be responsible for maintaining the pool 
of addresses available for assignment (for both NAT and DHCP). 

Command Line Interface / Soln Daemon - A command level control program to allow 
examination and re-configuration of the components of the server must be implemented. Primarily 
this will be for monitoring the Registration Device Driver and checkpointing the registration to disk 
for recovery purposes. It will support both an interactive command-line mode, as well as a daemon 
mode. It will normally run in the daemon mode. This daemon will accept notification that a user has 
registered or de-registered and update the device driver to allow/disallow network traffic for that 
client as appropriate. 

IPFW - The standard Linux packet filter IPF W (IP Firewall and Accounting) will be modified to 
perform filtering and redirection (of web and pop traffic initially) based on the stated information 
maintained by the Registration Device Driver. 

Ethernet/IP Packet Drivers - These must be modified to interface with Registration Device Driver 
to determine a guest's registration status, as well as to look up and apply any address translation to 
the packet headers. Both IP and MAC address information must be utilized in the lookup and 
translation, in case multiple guests are using the same IP address. 

DHCP Server - A DHCP server must be installed on the SolutionIP machine. The code for this 
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DHCP server must be modified so that it obtains new IP addresses to assign firom the Registration 
Device Driver, rather than fi-om its own pool of addresses to manage. 

POP Server - A pop server will be modified to provide any mail download request with one new 
mail message that would instruct the user to register using their web browser. Normally packets 
would only arrive at this server via redirection by the packet filter. 

WEB Server - A web server will be modified to redirect any requests to the registration system. 
Normally packets would only arrive at this server via redirection by the packet filter. 

Registration WEB Server - The web server and web pages that actually handle the registration 
dialog and communicate the registration state to the registration daemon. 

DNS Server - A Domain Name Service (DNS) server must be installed and configured on 
SolutionIP to provide local name resolution services to guests. This will serve as the primary DNS 
server for clients using DHCP. It will also service DNS requests from clients using fixed IP 
configurations which have been redirected to the DNS server by the packet drivers. 

4.2 DHCP Request Processing 

Figure 4-2 describes the processing performed by SolutionIP for DHCP requests: 
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Figure 4-2 DHCP Request Processing 
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When a guest with a computer configured for DHCP powers on. the computer initiates a DHCP 

^^^.^T'^^^" Driver. The Registration Device Driver provid^ 

appropnate IP address for the guest The IP address is returned to the DHCP server, which th^ 
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4.3 ARP Request Processing 

The processing performed for an ARP request is described in Figure 4-3, below: 



IPWorx Filed IP Stirtup 
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Figure 4-3 ARP Request Processing 

To identify exactly which machine on a LAN has a particular IP address, a guest's computer will 
initiate an ARP request, asking for the MAC address of the machine having the specified IP address. 
SolutionIP will detect the ARP request and respond with its own MAC address via the modified 
ARP server, regardless of the IP address actually requested. While processing the ARP request, the 
ARP server will notify the Registration Device Driver of the guest computer's MAC address and IP 
address. The Registration Device Driver can then detemune if a matching MAC address and IP 
address pair exists, as well as whether NAT will be required for the guest computer. The Registration 
Device Driver will then update its data structures with the new infonnation if necessary. 

4.4 Unregistered HTTP Request Processing 
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Processing of HTTP requests involves redirecting unregistered guests to the registration web server 
Md aUowing requests from registered guests to be routed normally. Processing of unregistered 
HTTP requests is shown in Figure 4-4. while processing of registered HTTP requests is shown in 
Figure 4-5 as an example of general IP based processing. 
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Figure 4-4 Unregistered HTTP Request Processing 

Processing of a Hypertext Transfer Protocol (HTTP) request begins with receipt of the request by 
SoIutionIP s packet drivers. These drivers query the Registration Device Driver to identify whether 
NAT translation of the packet headers is required. If required, the packet drivers perform this 
ttanslation. The IPFW component is then given control of the request. It queries the Registration 
Device Dnver to determine whether the guest is registered. If the guest is registered, it allows the 
request to be routed normally. If the guest is not registered, the request is passed to the modified 
Web Server, which translates it into a request for the registration area of the Registration Web 
Server. The translated request is then submitted to the Registration Web Server and the guest is 
presented with the hotel's registration screen. If the guest chooses to register for the network access 
service, this information is provided to the Control Program/Daemon, which updates the Registration 
Device Dnver appropriately. Subsequent requests from the guest computer following the update of 
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the Registration Device Driver will be processed as from a registered guest. 
4.5 Registered HTTP Request Processing 
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Figure 4-5 Registered HTTP Request Processing 
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The general processing performed by the SolutionIP server for IP-based traffic other than web and 
email trafBc is the same as shown in Figures 4-4 and 4-5, except that it is not subject to redirection. 
IP-based traffic initiates from the guest's computer and is sent to the SolutionIP server. The packet 
drivers on the SolutionIP server then determine whether the traffic requires NAT and performs 
translation on the headers if so required. The IPF W packet filter then determines whether the guest 
has registered for the network access service. If the guest is registered, the data traffic is allowed to 
proceed and is routed normally. If the guest has not registered, the data is blocked by discarding the 
incoming network packets. 
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1, INTRODUCTION 

This document describes the specific functional requirements for the initial release of the SolutionIP 
Billing System. It is expected that future development efforts will expand the functionality and 
administrative support options of the system. The cuirent emphasis is on rapid design and 
implementation of a solid, minimal system that vnll not interfere with the future implementation of 
advanced functionality. 

This release will support two methods of registration, access codes and port identification. Access 
codes will be generated for each room on a daily basis. Clients must enter the access code for their 
room as part of the registration process. Port identification will automatically determine the client's 
room number by querying the network switch infi-astructure to determine tiie specific switch port 
fi-om which the client is connected. Switch ports will be mapped to specific rooms. Access codes can 
be xised m the event the client is not connecting from a guestroom, such as when working fix)m a 
public area in the hotel, or if the switch port cannot be determined. 

Authorization codes will be supported as an override mechanism to apply special processing rules 
(discounts, fi-ee usage, etc.) to particular clients. This release of the system will store and display the 
authorization code as part of the billing report. The interpretation and application of authorization 
codes will be the responsibility of hotel staff. 

The hotel Property Management System (PMS) will perform the actual billing of clients. The billing 
system will provide web-based reports which can be printed and manually entered in the PMS by 
hotel staff. 

This document will describe in detail the core functionality of the billing system. The specific 
components comprising the system will be identified and described in detail. The requirements for 
the billing database will be presented, as well as a description of the billing system interface and 
reports. 
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2. REFERENCES 



The following documents contain information relevant to this functional specification. 

•H1260-001 - Draft Functional Specification for Solutioninc Ltd. - 10 June 1998; 
•H1260-001 - SolutionIP Technical Support Manual Draft - 8 April 1999; and 
•RFC 1493 - SNMP Bridge MIB, 
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3. REQUIREMENTS 

SolutionIP requires two Pentium class systems operating at 200 MHz or greater. One functions as 
the SolutionIP server while die other hosts the web site and database. These machines require the 
following hardware: 

.64MB RAM; 
•4.5GB hard drive; 

•Network Interface Card (NIC) (Linux compatible) NOTE: The SolutionIP server requires 
two NICs and the web server requires one; 
•Monitor and keyboard are optional; and 
•Two serial ports. 

The client component has the following requirements: 

•Network Interface Card and connector; 
•Web browser; 
•TCP/IP stack; and 

•A printer connection will be required for billing reports. 

SolutionIP must support a variety of client operating systems including Win95, Win98, WinNT, 
Macintosh OS 8 and Linux. 

The switches for port identification must support: 

•Bridge MIP (RFC 1493); 
•SNMP read access; and 
•1-1 mapping (room to port). 

The software requirements are based on the functionality of each machine: 
♦SolutionIP Server: 

•Operating System - RedHat Linux 5,1. 
•SolutionIP Web/Database Server: 
•Operating System - RedHat Linux 5.1; 
•Web Server - Apache; 
•Database - PostgreSQL 6.4 or higher; and 
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•Perl 5.004. 
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4. AREAS OF FUNCTIONALITY 

Three main areas of functionality exist for the billing system. These include port identification, 
access code generation and interpretation, and billing system administration. This section will 
present an overview of the general requirements of the system, as well as the specific requirements 
for each of the areas of functionality. 

a. Overview of Billing Requirements 

Billing will begin with the identification of the room associated with each client. Rooms will be 
identified either manually by associating an access code with a particular room, or automatically by 
obtaining the switch port the client is connected to and deriving tiie associated room. The system will 
provide facilities to automatically generate a new access code for each room, either for the current 
day or the next day. The codes will be displayed via a web page and can be printed. A configurable 
history of access codes will be maintained to prevent duplicate codes from being generated within 
the history period. No mechanism will be provided to prevent access codes firom being used more 
than once or by more than one client. Each new MAC registering will be billed to the associated 
room. Registrations will be valid until the next checkout time. The access code will be used to 
determine which room to bill, and so it will be the responsibility of the client to ensure that the code 
is kept secure. Billing will be based on the room firom which the client registers when using port 
identification. 

Once the room is identified, flie fee associated with that room will be determined. A flat fee per day 
will be associated with each room (different rates can be charged for different rooms). The 
registration interface will allow clients to enter special authorization codes. These codes will be 
stored with the client's billing information. Authorization codes used will be included in the billing 
report generated for hotel staff, but wdll not actually affect the fee generated by the billing system. 
Interpretation and application of authorization codes will be the responsibility of the hotel staff. 

A web-based billing report will be provided and printed by the hotel stafif. It will display who has 
been online since the last checkout time. Additional queries for arbitrary dates will also be available. 
These will show who was online firom checkout time on the specified day until checkout time the 
next day. Information included in the report will include client room, registration time, access code, 
port, authorization code, and fee. Access to all administrative web reports will be password 
protected. 

The database mxist be capable of storing one month worth of data. Backup, restoration, and disaster 
recovery procedures are not required. 
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b.Port Identification 

One method of associating a client (MAC Address) with a Room for billing purposes will be Port 
Identification. If, on registration, the physical port connection can be identified as being associated 
with a room, then that client's registration will be billed to that room. To determine what physical 
port a client is connected to the Simple Network Management Protocol (SNMP) will be used to 
discover which switch port they are talking to, static data tables are then used to determine the room 
nxmiber. 

•The switch/port number that a MAC is using will be determined by using SNMP to search the 
installation's switches. 

• Mapping from the switch/port mmiber that a MAC appears on will identify physical ports. This 
mapping will be maintained in the database. 

•Physical ports will map to room numbers and billing rates. These mappings will be maintained 
in the database. 

•The determination of the MAC to physical port mapping will be done on an as required basis. 

•If port identification is available it will take precedence over access code identification and no 
access code will be requested of the user during the registration process. The exception to this 
would be physical ports flagged as requiring a valid access code for registration to succeed. 

c. Access Code Identification 

An alternative to Port Identification is Access Code Identification. Each access code will be 
associated with a particular room and will be valid for a limited time period (usually one day from 
checkout time to checkout time). If port identification fails or is not available on a given port then 
the client will be prompted for an access code which the system then validates. This will ensure that 
a billing record is generated for the appropriate room. 

Access codes must be: 

•generated daily; 
•6 characters long; 

•comprised of capital letters and digits determined randomly with the following omissions: ' 1 ' 
(one), 'L\ 'O' (oh), '0' (zero), (two), *Z', 'U', 'V; 
•unique for some historical period (30 days by default); 
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•associated with a specific room number and billing rate; 

•used if port identification cannot be made for a MAC requesting registration, or if the physical 
port is flagged as requiring an access code; and 

•entered in either case, but Avill be converted to uppercase during processing. 

dAdministrative Features 

This section of the document will describe the administrative features incorporated into this release 
of the billing system. The administrative features will serve as the interface between the billing 
system and the hotel staff. The two features included in this release are the billing and access code 
reports. 

i. Billing Report 

The billing report will provide information to the hotel staff regarding room numbers, access codes, 
authorization codes, physical ports, registration time and fees. The report will be web-based and 
viewable from a standard web browser. The hotel staff will be able to generate and view the report 
on an as-needed basis. 

The following are mandatory requirements for the billing report, the report must: 
•produce a web-based billing report in a printable form; 

•include all charges to be applied to each room (not including special promotions or discounts); 
•be displayed in an organized, clear, and easy to read format, sorted by room number; 
•include the ability to view reports for dates other than the current billing period; 
•only be accessible to hotel staff responsible for billing; 

•include the room number, access code, authorization code, physical port, registration date and time, 
MAC address, and fee for each connection; 

•report charges from checkout time of the specified day until checkout time the next day; and 
•reports for the current day will show charges from the last checkout time until the current time. 

ii. Access Code Generation and Report 

The access code report will provide hotel staff with the information related to room numbers and 
access codes. The report will be web-based and viewable from a standard web browser. The hotel 
staff will be able to generate and view the report on an as-needed basis. Upon reviewing a report, 
the system will automatically generate access codes for the current or the following day if they do 
not exist in the database. 
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The access code report must: 

•produce a web-based access code report in a printable form; 
•be displayed in an organized, clear, and easy to read format, sorted by room number; 
•only be accessible by the hotel staff responsible for handling the access codes; 
•include the ability to view access codes for dates other than the current date; 
•include each room number and its associated access code; and 

•automatically initiate generation of new access codes for the current or next day if they do not exist 
when the report is requested. 



23 April 1999 



4-14 



CA 02293765 1999-12-23 



Version 1.0 



Draft Functional Specification 



Document # HI 260-06-003 



5. 



FUNCTIONAL COMPONENTS 



a. 



Overview 



The billing system will consist of components ruiming on both the SolutionIP Server and the Web 
Server. The Web Server will host the billing and configuration database, the Admin Interface which 
will be part of the Admin web site and the Registration Interface which will be the existing 
Registration Web pages with modifications to acconunodate the new billing system methods. On 
the SolutionIP Server the Registration Driver and Command Line Daemon will be modified to 
acconmiodate the new billing system methods. Two new daemons, the Synchronization Daemon 
and the SNMP Daemon, wdll be implemented to support the billing system and fiiture functionality. 

Figiire 5-1 displays a flow diagram of the interaction between the two servers and the suites and 
clients. 
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Figure 5-1 Flow Diagram 



b. Database 

The SolutionIP Billing System will be implemented using a PostgreSQL 6.4 database. The database 
will store configuration infonnation, access codes, and billing records. One month of data will be 
maintained at any given time. Data older than one month will be regularly purged fi-om the database. 
Database backup and recovery procedures are not required. 

Configuration data handled by the database will include switch configuration information (switch 
addresses, types, mappings of switch ports to rooms, etc.). Hotel checkout time, amount of data 
history to maintain, and other related parameters will also be stored in the database. 

The database will store the access code and its effective dates for each room. By default, each code 
will only be effective for one day. A history of access codes for each room will be kept. New codes 
will be checked against this history to prevent duplication. 

Billing records will identify the room to be billed for each connection. The following fields will be 
included in this record: 

•room niunber; 
•port registered firom; 
•access code used; 
•authorization code; 
•registration date and time; and 
♦type of fee to be charged. 

In certain cases, some fields may be NULL. For example, the access code would normally be NULL 
when port identification is being used. 

c. Command Line Daemon 

This section of the document will describe the modifications and additions to the conunand line 
daemon for this release of the billing system. The daemon requires the ability to handle multiple 
simultaneous requests from other systems, preserve parameter changes and track the state of 
registration driver backups. The daemon also requires modifications to reflect the changes to the 
Registration Driver and to accommodate the addition of the SNMP and Synchronization daemon. 
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i. General 

The Command Line Daemon must support: 

1. multiple (simultaneous) requests; 

2. persistent configuration parameters; and 

3. automatic restoration of the last valid driver backup. 

ii. New Registration Driver Interface Functions 

The Command Line Daemon is the primary interface into the registration driver. Therefore, 
modifications and additions to the driver will affect the daemon. The functionality of the registration 
driver will change to accommodate the billing system. The Command Line Daemon will provide 
interfaces to all new functionality created in the registration driver. Additionally, existing interface 
functionality will change to allow operations based upon physical port and room number. 

The Command Line Daemon will be modified to support the following new operations: 

•set the original room and port id for a specified user; 
•set the current room and port id for a specified user; 
•block a specified user, so they can not register; 
•unblock a specified user, so they can register; 
•flag a specified entry as permanent; 
•flag a specified entry as no longer permanent; and 

•set a grace period (time period prior to checkout, during which registrations will not expire until 
checkout time the next day). 

ill. Interface to SNMP Daemon 

The billing system will communicate with the SNMP Daemon via the Command Line Daemon. The 
Command Line Daemon will channel all traffic between the other billing system components and 
the SNMP Daemon. The Command Line Daemon will also update the Registration Driver, where 
applicable, with the results received fi^om the SNMP Daemon. 

The Command Line Daemon will: 

•respond to requests for port id resolution fi^m both the registration server and kernel drivers; 
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•forward requests for port id resolution to the SNMP Daemon; 
•receive port ids back firom the SNMP Daemon; 
•pass port id information back to requestor; and 

•inform the kernel of port id information if the kemei was not the requestor of the transaction. 
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d.SNMP Daemon 

The purpose of the SNMP Daemon will be to resolve MAC addresses to their physical port number, 
or return an error if this is not possible. This Daemon will use SNMP to interrogate the network 
switches to find the switch port that the client is connected to and then use static data tables to map 
that switch port to a physical port number. 

•Configuration data will be obtained firom flat data files stored on the SolutionIP Server; 
•Configuration data files will be derived firom database tables and updated by the Synchronization 
Daemon; 

•When Configuration files are changed the SNMP Daemon will be informed by the Synchronization 
Daemon; and 

•Requests and responses will be handled through standard Interprocess Communication Methods 
to other components on the system. 

e. Registration Driver 

The Registration Driver will require some modifications to support billing and production 
requirements. These changes are outiined in this section. The current driver maintains information 
on client MAC addresses, original IP addresses, and assigned IP addresses. Timing parameters are 
included to allow fixed-length registration periods, as well as inactivity timeouts for unregistered 
clients. 

A Time of Day expiry mode will be added. The method of expiration will be determined at the time 
of client registration. Under the Time of Day expiry mode, registrations will expire at the next 
checkout time (or any arbitrary time each day). Currentiy new registrations are expired at the end 
of a fixed time interval, typically 24 hours. The Time of Day expiry mode is more consistent with 
normal hotel billing routines. The existing expiry calculation mode v^U be preserved as an option. 

In addition to the new expiry mode, the ability to override parameters for individual clients will also 
be developed. Existing driver parameters server as defaults, and affect all clients. The new override 
mechanism will allow administrators to change specific parameters on a client-by-client basis. An 
example might be to extend the expiry time of a particular client, without affecting the expiry times 
of other clients. 
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In addition to operating on MAC and IP information, the driver will be modified to include room 
and port data. The work of associating rooms and ports with clients in the driver will be performed 
by external components (the billing system and SNMP daemon). Operations supported by the driver, 
such as registering or deleting entries, will be modified to allow such operations to be performed on 
all clients associated with a particular room or port. 

Production requirements include the ability to reserve specific addresses or make entries permanent. 
This is important to support maintenance access to network devices, such as switches, which reside 
on the client side of the SolutionIP servers. A mechanism to block particular clients should also be 
implemented. This mechanism would identify clients by room, port, or MAC. Blocked clients would 
be able to access the registration server and other services available to unregistered guests, but they 
would be prevented from registering for fall system access. 

f. Synchronization Daemon 

The purpose of the Synchronization Daemon will be to centralize access to the database by 
components of the SolutionIP Server through one interface. The daemon will use information stored 
in the database to create flat configuration files on the SolutionIP server. This allows configuration 
information for the various components to be centralized in the database but does not preclude their 
being maintained on the server if a database is not available or required at a particular installation. 

When files are updated by the Synchronization Daemon, the processes that use them will be 
informed that an update is available (possible methods of communicating this include signals, IPC 
semaphores or having the process monitor the last modified time of its configuration files). 
Eventually it will become desirable to have this process update information in the database based 
on status files from the SolutionIP server. 
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6. Interface 

This section of the document will describe the interface for this release of the billing system. The 
user interface will be web-based and viewable fi-om a standard web browser. Also documented is 
the interface between the web server and the registration system. 

a. Administration 

The administrative interface is available to users requiring access to the systems administrative 
features. The administrative interface components are described in the following sections: main 
administration, billing reports and access code reports. 

i. Main Administration 

The main admin web page serves as a home to the administrative functionality of the system. The 
page consists of the reports, administration and maintenance sections. Each section lists items of 
functionality appropriate to that section. The items are accessible using a standard hypertext link or 
via an imagemap. For this release of the billing system, there are two new report items: billing 
reports and access code reports. It is expected that there will be new report, administrative and 
maintenance items in future releases. 



ii. Billing Report 

The billing report interface allows users to view room, access code, authorization code, registration 
time, physical port and fee data, sorted by room, for a particxilar billing period. (See Figure 6- 1 ). 

•The billing report header will include the title and reporting period. 

•The billing report will display the current day's information by default. 

•The user can view reports for different dates using the navigation form located beneath the header. 
The navigation form includes two shortcut buttons for access to the previous or next day's billing 
data. It also includes a date entry field that allows users to view billing information for an arbitrary 
date. The date entry fields will contain default values equal to the last date processed (today's by 
default). A date is specified by entering a day in a two character input field, choosing a month from 

23 April 1999 6-22 



CA 02293765 1999-12-23 



Version 1.0 



Draft Functional Specification 



Document # H1260-06-003 



a drop down selection box, and entering a year in a four character input field. 

•The billing data for the specified date will be appear in tabular format. Columns will be clearly 
labeled and table data formatted to maximize readability, 

•In order to ensure that the data is easy to print, no flames will be used. 
•All of the report data will appear on a single HTML page. 

•The report data table will show the following information, sorted by room number: 

• room numbers; 

•fees; 

•registration dates and times; 
•access codes; 
•authentication codes; 
•MAC addresses; and 
•physical ports. 

•If no bming data exists for the date specified, then an enror message will be displayed. 

iii. Access Code Generation and Report 

The access code report interface allows users to view room and access code data, sorted by room, 
for a particular date. It also generates new access codes as required. (See Figure 6-2). 

•The access code report header will include the title and reporting period. 

•The access code report will display the current day's access codes by default. 

•The user can view access codes for different dates by using the navigation form located beneath 
the header at the top of the report. The navigation form includes two shortcut buttons for access 
to the previous or next day's access codes. It also includes a date entry field that allows users 
to view billing information for an arbitrary date. The firee form date area will contain defeult 
values equal to the last date processed (today's by default). A date is specified by entering a day 
in a two character input field, choosing a month fi-om a drop down selection box, and entering 
a year in a four character input field. 

•The access codes for the specified date will be appear in tabular format. Columns will be 
clearly labeled and table data formatted to maximize readability. 
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•In order to ensure that the data is easy to print, no frames will be used. 

•All of the report data will appear on a single HTML page. 

•The access code table will show: 
• room numbers; and 
•access codes. 

•Access codes will be generated automatically for the cxirrent date or the following date if 
they do not exist when requested. 

•If the specified date is not within the current history period, the current date, or the following date, 
an error message will be generated. 

b. Web Server Registration Process 

The existing registration process will be modified to take advantage of the new billing system 
methods. When a client attempts to register, the system will first attempt to determine if they are 
connecting firom a room that allows billing via the port identification method. If a billable room is 
identified using this method then the user will be presented with the Authorization - Confirmation 
Screen. If a billable room cannot be identified using the Port Identification Method then the Access 
Code Identification method will be used. The user will be presented with an access code entry 
screen, when the user enters a valid access code then the billable room will have been identified and 
they will be presented with the Authorization - Confirmation Screen. The Authorization - 
Confirmation Screen will present the user with the room number and rate and any other important 
information. The user will also be given the opportunity to enter an optional Authorization Code. 
Once the user confirms their willingness to pay the specified rate they will then be taken to The 
Virtual Concierge. 
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